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We study the problem of computing all Pareto-optimal journeys in a public 
transit network regarding the two criteria of arrival time and number of transfers 
taken. We take a novel approach, focusing on trips and transfers between them, 
allowing fine-grained modeling. Our experiments on the metropolitan network 
of London show that the algorithm computes full 24-hour profiles in 70 ms after 
a preprocessing phase of 30 s, allowing fast queries in dynamic scenarios. 


1. Introduction 


Recent years have seen great advances in route planning on continent-sized road net¬ 
works [j^ . Unfortunately, adapting these algorithms to public transit networks is harder 
than expected Q . On road networks, one is usually interested in the shortest path between 
two points, according to some criterion. On public transit networks, several variants of 
point-to-point queries exist. The simplest is the earliest arrival query, which takes a departure 
time as an additional input and returns a journey that arrives as early as possible. A natural 
extension is the multi-criteria problem of minimizing both arrival time and the number of 
transfers, resulting in a set of journeys. A profile query determines all optimal journeys 
departing during a given period of time. 

In the past, these problems have been solved by modeling the timetable information as 
a graph and running Dijkstra’s algorithm or variants thereof on that graph. Traditional 


graph models include the time-expanded and the time-dependent model [14]. More recently. 


algorithms such as RAPTOR [ jl^ and Connection Scan [ 1TT] | have eschewed the use of graphs 
(and priority queues) in favor of working directly on the timetable. 

In this work, we present a new algorithm that uses trips (vehicles) and the transfers 
between them as its fundamental building blocks. Unlike existing algorithms, it does not 
assign labels to stops. Instead, trips are labeled with the stops at which they are boarded. 
Then, a precomputed list of transfers to other trips is scanned and newly reached trips are 
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labeled. When a trip reaches the destination, a journey is added to the result set. The 
algorithm terminates when all optimal journeys have been found. 

A motivating observation behind this is the fact that labeling stops with arrival (or depar¬ 
ture) times is not sufficient once minimum change times are introduced. Some additional 
information is required to track which trips can be reached. For example, the realistic time- 
expanded model of P 3 T:ga et al. [ ]l6[ | introduces additional nodes to deal with minimum 
change times, while Connection Scan [ ]11[ | uses additional labels for trips. In contrast, once 
we know passengers boarded a trip at a certain stop, their further options are fully defined: 
Either they transfer to another trip using one of the precomputed transfers, or their current 
trip reaches the destination, in which case we can look up the arrival time in the timetable. 
In either case, there is no need to explicitly track arrival times at intermediary stops. 

The core of the algorithm is similar to a breadth-first search, where levels correspond to 
the number of transfers taken so far. As a result, it is inherently multi-criterial, similar to 
RAPTOR [ 101. Although a graph-like structure is used, there is no need for a priority queue. 
A preprocessing step is required to compute transfers, but can be parallelized trivially and 
only takes minutes, even on large networks (Section Q. By omitting unnecessary transfers, 
space usage and query times can be improved at the cost of increased preprocessing time. 

Section [^introduces necessary notations and definitions, before Section [^describes the 
algorithm and its variants. Sectionj^presents the experimental evaluation. Finally, Sectionj^ 
concludes the paper. 


2. Preliminaries 


2.1. Notation 


We consider public transit networks defined by an aperiodic timetable, consisting of a set 
of stops, a set of footpaths and a set of trips. A stop p represents a physical location where 
passengers can enter or exit a vehicle, such as a train station or a bus stop. Changing 
vehicles at a stop p may require a certain amount of time AT(,h(p) (for example, in order 
to change platforms) j^footpat/is allow travelers to walk between two stops. We denote the 
time required to walk from stop pi to p 2 by ATfp(pi,p 2 ) and define ATfp(p,p) = ATf.-^[p) 
to simplify some algorithms. A trip t corresponds to a vehicle traveling along a sequence of 
stops p(t) = ,Pf,.. .^. Note that stops may occur multiple times in a sequence. For each 
stop pj, the timetable contains the arrival time i) and the departure time T(jep(t, 0 of 

the trip at this stop. Additionally, we group trips with identical stop sequences into hne.0 
such that all trips t and u that share a line can be totally ordered by 

t ^ U Vt e [o, |p(t)|) : Tarr(t,pO < '^arr(n,p;,) (D 

and define 

t-<u<=^ t ^ u Adi e [o, |p(t)|) : Tan.(t,pQ < Ta„(u,p;^) . (2) 


^More fine-grained models, such as different change times for specific platforms, can be used without affecting 
query times, since minimum change times are only relevant during preprocessing (Section 3.11. 

^We chose line over route to avoid confusion with routing and the usage of route in the context of road networks. 
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If two trips have the same stop sequence, but cannot be ordered (because one overtakes the 
other), we assign them to different lines. We denote the line of a trip t by Lf and define 
p(Lf) = p(t). We also define the set of lines at stop p as 


L(p) = |(L, t) p = Pi where L is a line andp(L) = (pi,pl, •••)}• 


(3) 


A trip segment p^ —> represents a trip t traveling from stop p^ to stop p^. A transfer 
between trips t and u {t is denoted by p^ —> p^, where passengers exit t at the eth stop 
and board u at the bth. For all transfers. 




■ p^ 


I.(t,e) + ATfp(p^,p^) <T<iep(u,b) 


(4) 


must hold. Finally, a journey is a sequence of alternating trip segments and transfers, with 
optional footpaths at the beginning and end. Each leg of a journey must begin at the stop 
where the previous one ended. 

We consider two well-known problems. Since both of them are multi-criteria problems, the 
results are Pareto sets representing non-dominated journeys. A journey dominates another if 
it is no worse in any criterion; if they are equal in every criterion, we break ties arbitrarily. 
Although multi-criteria Pareto optimization is NP-hard in general, it is efficiently tractable for 


natural criteria in public transit networks [ 15 ]. In the earliest arrival problem, we are given 
a source stop a target stop p^gj, and a departure time t. The result is a Pareto set of 
tuples (Tjai-r; ti) of arrival time and number of transfers taken during non-dominated journeys 
from Psfc to pjgt that leave no earlier than t. For the profile problem, we are given source stop 
Psrcj target stop p^gt, an earliest departure time Tg^tj and a latest departure time Ti^t. Here, 
we are asked to compute a Pareto set of tuples (Tj^gp, n) representing non-dominated 
journeys between pg^g and pjg^ with Tg^jj < Tj^ep ^ 'tidt- Note that for Pareto-optimality, later 
departure times are considered to be better than earlier ones. 


2.2. Related work 

Some existing approaches solve these problems by modeling timetable information as a 
graph, using either the time-expanded or the time-dependent model. In the (simple) time- 
expanded model, a node is introduced for each event, such as a train departing or arriving at 
a station. Edges are then added to connect nodes on the same trip, as well as between nodes 
belonging to the same stop (corresponding to a passenger waiting for the next train). To 


model minimum change times, additional nodes and edges are required [16]. One advantage 


of this model is that all edge weights are constant, which allows the use of speedup techniques 
developed for road networks, such as contraction. Unfortunately, it turns out that due to 
different network structures, these techniques do not perform as well for public transit 
networks [Q . Also, time-expanded graphs are rather large. 

The time-dependent approach produces much smaller graphs in comparison. In the 
simple model, nodes correspond to stops. Edges no longer have constant weight, but are 
instead associated with (piecewise linear) travel time functions, which map departure times 
to travel times (or, equivalently, arrival times). The weight then depends on the time at 
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which this function is evaluated. This model can be extended to allow for minimum change 
times by adding a node for each line at each stop [ 161. Some speedup techniques have 
been applied successfully to time-dependent graphs, such as ALT [j^ and Contraction [ 12 ], 
although not for multi-criteria problems. For these, several extensions to Dijkstra’s algorithm 
exist, among them the Multicriteria Label-Setting [ 131, the Multi-Label Correcting [|^, the 
Layered Dijkstra [|^, and the Self-Pruning Connection Setting [j^ algorithms. However, as 
Dijkstra-variants, each of them has to perform rather costly priority queue operations. 

Other approaches do not use graphs at all. RAPTOR (Round-bAsed Public Transit Optimized 
Router) [ 101 is a d 3 mamic program. In each round, it computes earliest arrival times for 
journeys with n transfers, where n is the current round number. It does this by scanning 
along lines and, at each stop, checking for the earliest trip of that line that can be reached. 
It outperforms Dijkstra-based approaches in practice. The Connection Scan Algorithm [ ]11[ | 
operates on elementary connections (trip segments of length 1). It orders them by departure 
time into a single array. During queries, this array is then scanned once, which is very fast in 
practice due to the linear memory access pattern. 

A number of speedup techniques have been developed for public transit routing. Transfer 
Patterns [j^[^ is based on the observation that for many optimal journeys, the sequence of 
stops where transfers occur is the same. By precomputing these transfer patterns, journeys can 
be computed very quickly at query time. Public Transit Labeling Q applies recent advances in 
hub labeling to public transit networks, resulting in very fast query times. Another example is 
the Accelerated Connection Scan Algorithm [ {TtI I, which combines CSA with multilevel overlay 
graphs to speed up queries on large networks. The algorithm presented in this work, however, 
is a new base algorithm; development of further speedup techniques is a subject for future 
research. 


3. Algorithm 

3.1. Preprocessing 

We precompute transfers so they can be looked up quickly during queries. A key observation 
is that the majority of possible transfers is not needed in order to find Pareto-optimal journeys, 
and can be safely discarded. Preprocessing is divided into several steps: Initial computation 
and reduction. Initial computation of transfers is relatively straightforward. For each trip t 
and each stop pj of that trip, we examine pj and all stops reachable via (direct) footpaths 
from pj. For each of these stops q, we iterate over (L,i) e h(q) and find the first trip u 
of line L such that a valid transfer p j —> pi satisfying (|^ exists. Since, by definition, trips 
do not overtake other trips of the same line, we can discard any transfers to later trips of 
line L. Additionally, we do not add any transfers from the first stop (t = 0) or to the last 
stop (j = |p(L)| — 1) of a trip. Furthermore, transfers to trips of the same line are only 
kept if either u -< t or j < i; otherwise, it is better to simply remain in the current trip. See 
Algorithmic for a pseudocode description of this. 

After initial computation is complete, we perform a number of reduction steps, where we 
discard transfers that are not necessary to find Pareto-optimal journeys. First, we discard any 
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Algorithm 1 Initial transfer computation 

Input: Timetable data 


Output: Transfer set T 


1 

T^0 


2 

for each trip t do 


3 

for each stop p‘ on trip t with i > 0 do 


4 

for each stop q such that ATfp(^p‘,qj is defined do 


5 

for each line (L, j) e i(q) with j < |p(L)| — 1 do 


6 

u <— earliest trip of line L such that i) ■+■ ATfp(^p‘,qj 

< '^depiuj) 

7 

if L 7 ^ Lf V u -< t V ;■ < t then 


8 

T^TLl(j)[^pCj 

> Add transfer 


Algorithm 2 Remove U-turn transfers 

Input: Timetable data, transfer set T 
Output: Reduced transfer set T 
1 : for each transfer pi do 

2 : ifpp^ ATarrCUi - l) + ATeh(pt“^) < T^depiuJ + l) then 

3: T <— T \ p‘ —> Pu > Remove U-turn transfer 


transfers p‘ —> pi where pi^^ =p\ ^ (we call these U-turn transfers) as long as 

Tarr(t,i-l) + ATch(prO - '^dep (“, j + l) (5) 

holds (Algorithm!^. In this case, we can already reach u from t at the previous stop, and 
because 

T^arrCUi-l) ^ 'tdep(Ui-l) ^ T^arrCUO 

<T^dep(u,;) < 'rarr(u,i + l) < 't depi^, j + l) , 

all trips that can reach t at the previous stop can also reach u, and all trips reachable from u 
are also reachable from t. Equation (|^ may not hold if the stops in question have different 
minimum change times. 

Next, we further reduce the number of transfers by analyzing which transfers lead to 
improved arrival times. We do this by moving backwards along a trip, keeping track of 
where and when passengers in that trip can arrive, either by simply exiting the trip or by 
transferring to another trip reachable from their current position. Again, we iterate over all 
trips t. For each trip, we maintain two mappings and from stops to arrival time and 
earliest change time, respectively. Initially, they are set to oo for all stops. During execution 
of the algorithm, they are updated to reflect when passengers arrive (t^) or can board the 
next trip (t^) at each stopj^ We then iterate over stops p‘ of trip t in decreasing index order, 
meaning we examine later stops first. At each stop, we update the arrival time and change 


^If there are no minimum change times, then and we only maintain t^. 
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Algorithm 3 Transfer reduction 


Input: Timetable data, transfer set T 
Output: Reduced transfer set T 
1 : for each trip t do 

2: oo > Arrival time at stops 

3: T^c(') ^ oo > Earliest change time at stops 

4: for i«—|p(t)| - do 

5: TA(pt) ^min(TA(pQ,Tarr(t,0) 

6: for each stop q such that Axfp (pj, q) is defined do 

7: T^A(q) ^niin(TA(q),Tai.r(t,0 +ATfp(p‘,q)) 

8: Tc(q) ^ min(Tc(q), i) + ATfp(p',q)) 


9 

10 

11 

12 

13 

14 

15 

16 

17 

18 


for each transfer Pf —> Pu ^ T do 
keep «— false 

for each stop p^ on trip u with fc > j do 
keep ^ keep V Tarr(u, fc) < t^a(Pu) 

'^a(Pu) ^min(TA(Pa),'7arr(u,fc)) 

for each stop q such that ATfp(^p^,qj is defined do 

V ^ T^arr(u, k) + ATfp (p^, q) 
keep «— keep V rj < V rj < T^Cq) 

TA(q) «-min(TA(q),'q) 

Tc(q)^min(Tc(q),p) 


if -ifceep then 
T^T\pi 


> No improvement, remove transfer 


time for that stop if they are improved: 

Tn(p',) ^ rnin(T^(p;).T„^(t,0) and 

<— min ('7c(Pt)’^arr(t>0 + ATeh(p;)) • 

Similarly, we update Ta and Tq for all stops q reachable via footpaths from p‘: 

TA(q) ^min(TA(q),Tarr(t,0 +ATfp(p[,q)) and 
Tc(q) ^ min(Tc(q), t) + ATfp (p‘, q)) . 

We then determine, for each transfer p' —> pi from t at that stop, if u improves arrival and/or 
change times for any stop. To do this, we iterate over all stops p^ of u with k> j and perform 
the same updates to Ta and as we did above, this time for p^ and all stops reachable via 
footpaths from p^. If this results in any improvements to either Ta or Tc, we keep the transfer, 
otherwise we discard it. Discarded transfers are not required for Pareto-optimal journeys, 
since we have shown that (a) taking later transfers (or simply remaining in the current trip) 
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leads to equal or better arrival times (t^), and (b) all trips reachable via that transfer can also 
be reached via those later transfers (tc). Refer to Algorithm]^ for a pseudocode description. 

All these algorithms are trivially parallelized, since each trip is processed independently. 
Also, there is no need to perform them as separate steps; they can easily be merged into 
one. We decided to keep them distinct to showcase the separation of concerns. Furthermore, 
more complex reduction steps are possible, where there are dependencies between trips. For 
example, to minimize the size of the transfer set, one could compute full profiles between all 
stops (all-to-all), then keep only those transfers required for optimal journeys. However, that 
would be computationally expensive. In contrast, the comparatively simple computations 
presented here can be performed within minutes, even for large networks, while still resulting 
in a greatly reduced transfer set (see Section]^ for details). 

Note that this explicit representation of transfers allows fine-grained control over them. 
For instance, one can easily introduce transfers between specific trips that would otherwise 
violate the minimum change time or footpath restrictions, or remove transfers from certain 
trips. Transfer preferences are another example. If two trips travel in parallel (for part of 
their stop sequence), there may be multiple possible transfers between them. The algorithm 
described above discards all but the last of them; by modifying it, preference could be given 
to transfers that are more accessible, for instance. Since this only has to be considered during 
preprocessing, query times are unaffected. 


3.2. Earliest Arrival Query 

As a reminder, the input to an earliest arrival query consists of the source stop the target 
stop Ptgj, and the (earliest) departure time t, and the objective is to calculate a Pareto set of 
nj tuples representing Pareto-optimal journeys arriving at time after n transfers. 
During the algorithm, we remember which parts of each trip t have already been processed 
by maintaining the index R(t) of the first reached stop, initialized to R(t) <— oo for all trips. 
We also use a number of queues Q„ of trip segments reached after n transfers and a set i? of 
tuples (L, i. At). The latter indicates lines reaching the target stop Ptgu ^nd is computed by 


.^ = {(L,t,0) (L,0ei(ptgt)} 

U |(^L, i, ATfp(^q,ptgtj j (L, i) e L(q) A 3 a footpath from q to p^gt j 


We start by identifying the trips travelers can reach from Ps^c at time t. For this, we examine 
Psfc and all stops reachable via footpaths from For each of these stops q, we iterate over 
(L, i) e l(q) and find the first trip t of line L such that 


Tdep(t>0> 


T-FATfp(psrc,q) 


if q = PsTC, 
Otherwise. 


For each of those trips, if i < R{t), we add the trip segment p j —> pf to queue Qq and then 
update R(u) <— min(R(u), i) where t u A = L^, meaning we update the first reached 
stop for t and all later trips of the same line. Due to the way is defined in Q, none of 


7 




Algorithm 4 Earliest arrival query 

Input: Timetable, transfer set T, source stop target stop departure time t 
Output: Result set J 
1: J^0 
2 : 

3: Q„ <— 0 for n = 0,1,... 

4: R(t) <— oo for all trips t 

5: for each stop q such that ATfp(^q,Ptgtj is defined do 
6: AT«-Oifptgt = q>else ATfp(q,ptgt) 

7: for each (L, i) e i(q) do 

8: i?«-i?U{(L,i,AT)} 

9: for each stop q such that ATfp(psj.(,,q) is defined do 
10: At ^ 0 if Psrc = else Axfp (p^^o q) 

11: for each (L, i) e i(q) do 

12: t <— earliest trip of L such that t + At < T(jep(t, i) 

13: ENQUEUE(t,i,0) 

14: T^jin «— OO 
15: n<—0 

16 : while Qn 0 do 

17: for eachpj —>p® eQ„ do 

18: for each (Lj, i, At) e i? with b < i and i) + At < Tj^j^ do 

19: Tjnin^ Tarr(t>0 +At 

20: J «— J U { (Tjnin, n) }, removing dominated entries 

21: ifTarrCt, b + l)<'7min dien 

22: for each transfer p‘ —> p^ e T with b < i < e do 

23: ENQUEUE(u, j,n+1) 

24: n «— n + 1 

1: procedure enqueue (trip t, index i, number of transfers n) 

2: if i<R(t) then 

3: 

4: for each trip u with t ^ u A Lj = do 

5: R(u) <—min(R(u), i) 


these later trips u can improve upon t. By marking them as reached, we eliminate them from 
the search and avoid redundant work. 

After the initial trips have been found, we operate on the trip segments in Qo,Qi,--- 
until there are no more unprocessed elements. For each trip segment pf —> p^ £ Qn, we 
perform the following three steps. First, we check if this trip reaches the target stop. For 
each (Lf, i. At) e i? with t > b, we generate a tuple (T^rrCt, i) + At, n) and add it to the 
result set, maintaining the Pareto property. Second, we check if this trip should be pruned 
because it cannot lead to a non-dominated journey. This is the case if we already found a 
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journey with Tja^r < b + 1). Third, if the trip is not pruned, we examine its transfers. 

For each transfer pj —> with b <i < e, we check if j < If so, we add p^ —> to 

Qn+i and update R(v) «— min(if(v), j) for all v with u :<v AL^ = L^. Otherwise, we already 
reached u or an earlier trip of the same line at j or an earlier stop, and we skip the transfer. 
A pseudocode description can be found in Algorithm]^ 

The main loop is similar to a breadth-first search: First, all trips reachable directly from the 
source stop are examined, then all trips reached after a transfer from those, etc. Therefore, we 
find journeys with the least number of transfers first. Any non-dominated journey discovered 
later cannot have a lower number of transfers and must therefore arrive earlier. This property 
enables the pruning in step two, which prevents us from having to examine all reachable 
trips regardless of the target. However, it also means that the journey with the earliest arrival 
time is the last one discovered, and all journeys with less transfers are found beforehand. 
This is why we only consider the multi-criteria problem variants. 

3.3. Profile Query 

We perform profile queries by running the main loop of an earliest arrival query for each 
distinct departure time in the given interval, preserving labels between runs to avoid redun¬ 
dant work. Later journeys dominate earlier journeys, provided arrival time and number of 
transfers are equal or better, while earlier journeys never dominate later ones. Therefore, 
we process later departures first. However, in order to reuse labels across multiple runs, we 
need to keep multiple labels for each trip, consisting of the index of the first reached stop 
and the number of transfers required to reach it. Since the number of transfers is limited 
in practice, we use Rn{t) to denote the first stop reached on trip t after at most n transfers 
and update if„_|_i(t) (and following) whenever we update il„(t). To decide if a trip segment 
should be queued while processing Q„, we compare against and update R„_|_i(t). We also 
change the pruning step so we compare against the minimum arrival time of journeys with 
no more than n -I- 1 transfers. 

To see why labels can be reused, consider two runs with departure times Tj and T 2 , where 
Tj < T 2 , which both reach trip t at stop t after n transfers. Continuing from this point, both 
will reach the destination at the same time and after the same number of transfers. However, 
since < T 2 , the journeys departing at T 2 dominate the journeys departing at t^. Knowing 
this, we can avoid computing them in the first place by computing T 2 first and keeping the 
labels. 

3.4. Implementation 

We improve the performance of the algorithm by taking advantage of SIMD (single instruction, 
multiple data) instructions, avoiding dynamic memory allocations and increasing locality of 
reference (reducing cache misses). In our data instances, all lines have less than 200 stops. 
Also, none of our tests found Pareto-optimal journeys with 16 or more transfers. Thus, we set 
the maximum number of transfers to 15. During profile queries, we can then update Ro[t) to 
Ris(t) using a single 128-bit vector minimum operation. 
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To avoid memory allocations during query execution, we replace the n queues with a 
single, preallocated array. To see why this is possible, note that the maximum number of trip 
segments queued is bounded by the number of elementary connections. We use pointers to 
keep track of the current element, the end of the queue, and the level boundaries (where the 
number of transfers n is increased). 

We improve locality of reference by splitting the steps of the inner loop into three separate 
loops. Thus, we iterate three times over each level, each time updating the elements in the 
“queue”, before increasing n and moving on to the next level. In the first iteration, we look 
up Tai-rCt) b + 1) and store it next to the trip segment into the queue. Additionally, we check 
if to see if the trip reaches the destination, and update arrival times as necessary. In the 
second iteration, we perform the pruning step by comparing the time stored in the queue 
with the arrival time at the destination. If the element is not pruned, we replace it with two 
indices into the array of transfers, indicating the transfers corresponding to the trip segment. 
If the element is pruned, we set both indices to 0, resulting in an empty interval. Finally, in 
the third iteration, we examine this list of transfers and add new trip segments to the queue 
as necessary. Thus, arrival times T^rrC-, •) are required only in the first loop, transfer indices 
only in the second loop, and transfers and reached stops only in the final loop. This 
leads to reduced cache pressure and therefore to less cache misses, which in turn results in 
improved performance (see Section Q. For more details on the data structures used, please 
refer to Appendix]^ 

3.5. Journey Descriptions 

So far, we only described how to compute arrival time and number of transfers of journeys, 
which is enough for many applications. However, we can retrieve the full sequence of trip 
segments as follows. Whenever a trip segment is queued, we store with it a pointer to the 
currently processed trip segment. Since we replaced the queue with a preallocated array, all 
entries are preserved until the end of the query. Therefore, when we find a journey reaching 
the destination, we simply follow this chain of pointers to reconstruct the sequence of trip 
segments. If required, the appropriate transfers between the trips can be found by rescanning 
the list of transfers. 


4. Experiments 

We ran experiments on a dual 8-core Intel Xeon E5-2650v2 processor clocked at 2.6 GHz, 
with 128 GB of DDR3-1600 RAM and 20 MB of L3 cache. Our code was compiled using 
g++ 4.9.2 with optimizations enabled. We used two test instances, summarized in Table 
The first, available at data . london. gov. uk, covers Greater London and includes data for 
underground, bus, and Docklands Light Railway services for one day. The second consists of 
data used by bahn . de during winter 2011/2012, containing European long distance trains, 
German local trains, and many buses over two days. 

Table also reports the number of transfers before and after reduction, as well as the total 
space consumption (for the reduced transfers and all timetable data). Reduction eliminates 


10 


Table 1: Instances used for experiments 



London 

Germany 

Stops 

20 764 

249 724 

Trips 

129263 

2389253 

Connections 

4991130 

46116453 

Footpaths 

45 624 

100470 

Lines (Routes) 

2161 

232644 

Transfers (full) 

121339213 

1826424894 

Transfers (reduced) 

19502 791 

186296771 

Space consumption 

115.5 MiB 

1140.9 MiB 


Table 2: Preprocessing times for transfer computation and reduction 



London 

London 

Germany 

Germany 


1 thread 

16 threads 

1 thread 

16 threads 

Computation 

18 s 

3s 

177s 

37s 

Reduction 

357 s 

27 s 

2174s 

183 s 

Total 

375 s 

30 s 

2351s 

220 s 


about 84% of transfers for London, and almost 90% for Germany. The times required for 
preprocessing can be found in Table 

Running times reported for queries are averages over 10000 queries with source and target 
stops selected uniformly at random. For profile queries, the departure time range is the 
first day covered by the timetable; for earliest arrival queries, the departure time is selected 
uniformly at random from that range. We do not compute full journey descriptions. 

We evaluated the optimizations described in Sectionas well as the effect of transfer 
reduction, on the London instance (Table . SIMD instructions are only used in profile 
queries and enabling them has no effect on earliest arrival queries. With all optimizations, 
running time for profile queries is improved by a factor of 2. Transfer reduction improves 
running times by a factor of 3. 

We compare our new algorithm to the state of the art in Table We distinguish between 
algorithms which optimize arrival time only (o) and those that compute Pareto sets optimizing 
arrival time and number of transfers (•), and between earliest arrival (o) and profile (•) 
queries. We report the average number of label comparisons per stop|^ where available, 
and the average running time. Direct comparison with the Accelerated Connection Scan 
Algorithm (ACSA) [ ]17[ | and Contraction Hierarchies (CH) [ 121 is difficult, since they do not 
support bicriteria queries]^ We have faster query times than CSA Jilt RAPTOR [ 101, 


'^Note that in our algorithm, labels are not associated with stops, but with trips instead. For better comparison 
with previously published work, we divided the total number of label comparisons by the number of stops. 
^ACSA uses transfers to break ties between journeys with equal arrival times. 
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Table 3: Evaluation of optimizations in Section 3.4 using the London instance 
variant earliest arr. (ms) profile (ms) 


Basic, without SIMD 

1.7 

145.9 

Basic, with SIMD 

1.7 

113.2 

Optimized 

1.2 

70.0 

Optimized, all transfers 

3.5 

226.0 


Table 4: Comparison with the state of the art. Results taken from 
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algorithms computing a set of Pareto-optimal journeys regarding arrival time and 
number of transfers are marked in column “tr.” (others only optimize arrival time). 
Profile queries are marked in column “pr.”. 


algorithm 


instance 


stops 

(• 10 ^) (• 10 '’) 


conn. 


tr. pr. 


prep. 

(h) 


comp. 

/stop 


TripBased 
TP [j^ 
PTL^ 
RAPTOR [ITOI 


CSA^] 

CH pfr 


London 
Madrid 
London 
London 
London 
Europe (LD) 


20.8 

4.6 

20.8 

20.8 

20.8 

30.5 


5.0 

4.8 
5.1 
5.1 

4.9 
1.7 


< 0.1 

185.0 

49.3 


< 0.1 


TripBased 

TP 

csA qQ] 
ACSATO] 


Germany 

Germany 

Germany 

Germany 


249.7 46.1 

248.4 13.9 

252.4 46.2 

252.4 46.2 


o o 
o o 


< 0.1 

372.0 

0.2 


query 

(ms) 


23.3 

n/a 

n/a 

10.9 

26.6 

n/a 


1.2 

3.1 

0.03 

5.4 

1.8 

0.3 


41.4 40.8 

n/a 0.3 

n/a 298.6 
n/a 8.7 


TripBased 

London 

20.8 

5.0 

• • 

<0.1 

1061.7 

70.0 

TP P 

1 


Madrid 

4.6 

4.8 

• • 

185.0 

n/a 

3.1 

rRAPTOR [ 

10 

1 London 

20.8 

5.1 

• • 

— 

1634.0 

922.0 

GSA [ 

11 

J 


London 

20.8 

4.9 

• • 

— 

3824.9 

466.0 

TripBased 

Germany 

249.7 

46.1 

• • 

<0.1 

228.0 

301.7 

TP [|3 

1 


Germany 

248.4 

13.9 

• • 

372.0 

n/a 

5.0 

AGSA 

[0 

Germany 

252.4 

46.2 

O • 

0.2 

n/a 

171.0 
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Figure 1: Earliest arrival query times by geo¬ 
rank on Germany 


Figure 2: Profile query times by geo-rank on 
Germany 


at the cost of a few minutes of preprocessing time. Transfer Patterns (TP) [|l]|^ and Public 
Transit Labeling (PTL) []^ have faster query times (especially on larger instances), however, 
their preprocessing times are several orders of magnitude above ours. 

To examine query times further, we ran 1000 geo-rank queries [ jl^ . A geo-rank query picks 
a stop uniformly at random and orders all other stops by geographical distance. Queries are 
run from the source stop to the 2''-th stop, where r is the geo-rank. Results for the Germany 
instance are reported in Figure [^(earliest arrival queries) and Figure [^(profile queries). Note 
the logarithmic scale on both axes. Query times for the maximum geo-rank are about the 
same as the average query time when selecting source and target uniformly at random, since 
randomly selected stops are unlikely to be near each other. Local queries, which are often 
more relevant in practice, are generally much faster (by an order of magnitude), although 
there is a significant number of outliers, since physically close locations do not necessarily 
have direct or fast connections. 


5. Conclusion 

We presented a novel algorithm for route planning in public transit networks. By focusing on 
trips and transfers between them, we computed multi-criteria profiles optimizing arrival time 
and number of transfers on a metropolitan network in 70 ms with a preprocessing time of just 
30 s, occupying a Pareto-optimal spot among current state of the art algorithms. The explicit 
representation of transfers allows fine-grained modeling, while the short preprocessing time 
allows the use in dynamic scenarios. In addition, localized changes (such as trip delays or 
cancellations) do not necessitate a full rerun of the preprocessing phase. Instead, only a 
subset of the data needs to be updated. Development of suitable algorithms is a subject 
of future studies. Future work also includes efficiently extending the covered period of 
time by exploiting periodicity in timetables, making the algorithm more scalable by using 
network decomposition, and extending it to support more generic criteria such as fare zones 
or walking distance. 
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A. Data Structures 

We assign consecutive integer IDs, starting from 0, to stops, lines, and trips. For trips, we 
assign IDs such that trips of the same line are consecutive, with earlier trips having lower 
IDs. An array maps lines to their first trip. We store the remaining data using a forward 
star representation. For example, to store footpaths, we use two arrays. Footpaths and 
Footpathindex. Footpaths contains information about footpaths, namely the destination 
stop and the length, for all footpaths. It is ordered such that footpaths starting at stop 0 
come first, then footpaths starting at stop 1, etc. Footpathindex contains, for each stop, 
the index of the first footpath starting at that stop (plus a sentinel value equal to the size of 
Footpaths). To examine footpaths at stop i, we iterate from Footpaths [ Footpathindex [i] ] 
to Footpaths [ Foot pat hlndex[i -F 1 ] ]. The lines at each stop and the stops on each line are 
similarly stored. For arrival times, we store all times of the first trip in order, then all times 
of the second trip etc. and store the index of the first entry for each trip. Thus, T^^ft, i) is 
implemented by looking up ArrivalTimes [TripTimeIndex [ t] -Fi ]. Departure times use the 
same index array, as do transfers, albeit with an additional indirection: Transfers from trip 
t at index i can be found starting at Transfers [TransferIndex[TripTimeIndex[ t] + i] ]. 
For the transfers themselves, we only store the target trip and board index. Finally, we 
redundantly store an array mapping trips to lines and a second list of footpaths, this time 
indexed by their destination stops. Although not strictly necessary, these allow fast lookups 
during queries. 
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